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ABSTRACT 



A content server using an object database supports a network 
of multiple User clients. The database is loaded with virtual 
objects which constitute source documents in the form of a 
multiplicity of resource objects, which may be file-oriented 
objects or message -oriented objects, which enable the for- 
mat of any source document to be converted to another 
format compatible for transport via an appropriate protocol 
to a requesting client User. The resource objects include a 
multiplicity of converter objects which are defined and 
placed in the database to provide format transformation from 
the format of the original source document content into the 
format required by a calling requester. The object database 
will be searched to find the proper converter object to 
transform the contents of the source document into the 
required format for the calling requester's facilities or for 
transmittal to a digital appliance in a protocol appropriate to 
the receiving requester or digital appliance. 
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SELECTIVE MULTIPLE PROTOCOL 
TRANSPORT AND DYNAMIC FORMAT 
CONVERSION IN A MULTI-USER 
NETWORK 

FIELD OF THE INVENTION 

This disclosure relates to computer-implemented systems 
for automatic conversion of content format to accommodate 
formatting and protocol requirements of multiple client 
users. 

REFERENCES TO RELATED APPLICATIONS 

This application relates to the following co- pending appli- 
cations which are incorporated herein by reference: 

U.S. Sen No. 08/768,387 entitled "Automatic Format 
Conversion System and Publishing Methodology in Multi- 
User Network"; 

U.S. Ser. No. 08/769,199 entitled "A Method for Storing 
Files of Various Formats in an Object Database Using a 
Virtual Multimedia File System"; and 

U.S. Ser. No. 08/769,200 entitled "A Method for Abstract- 
ing Messages of Various Protocols Into Objects For Storage 
in a Database", filed Dec. 18, 1996, now U.S. Pat. No. 
5,794,039 issued Aug. 11, 1998. 

BACKGROUND OF THE INVENTION 

In the rapidly developing area of digital technology, there 
is an expanding use of networks with multi-client users 
which can be connected to the multitudinous terminals of the 
Internet or to the limited number of terminals in an Intranet 
set-up for a particular group or set of clients. 

Such type of networks with multiple numbers of con- 
nected clients present many problems in that many of the 
client stations are limited to particular types of content 
format and protocol delivery. Further, when it is desired to 
communicate with FAX machines and telephones, in addi- 
tion to e-mail, again, there are specialized formats and 
protocols that are required to enable these types of commu- 
nications to take place with these specialized appliances or 
terminals. 

It has become more and more desirable to provide sys- 
tems and methodology which enable clients using one type 
of personal computer and its specialized protocol require- 
ments to communicate with other clients having different 
personal computers with different formats and protocol 
requirements. Likewise, it is desirable to enable a user 
client's personal computer, using one type of protocol, to be 
able to communicate with FAX machines, telephones and 
e-mail clients, which require different content formats and 
different protocols for communication delivery. 

Earlier network technologies and even the majority of 
present network technologies involve slow and complex 
software systems and methods in order to enable a client 
having a document in one particular format, and using a 
particular protocol to communicate with another client ter- 
minal having a different protocol or with terminals having 
the protocols and formats used for the FAX machine or the 
protocols used for the telephone. These often involve long, 
drawn-out translation procedures which were slow, cumber- 
some and subject to reliability problems. 

It would be most desirable to provide a network where 
any client, no matter what format his document consists of, 
or what his personal computer protocol system utilizes, 
could create, originate or author a document and enable this 
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document's content to be suitably formatted for transmittal 
to and reception by personal computer clients or appliances 
requiring specialized formats and different types of protocol 
so as to be received by appliances such as FAX machines, 

5 telephones and e-mail users. Heretofore, this has not been 
done with any great efficiency whereby an originator or 
author could originate a text or message in his own personal 
format and, using his personal appliance protocol, send it to 
multiple receiver users and multiple receiver appliances 

10 without any further complications other than sending his text 
or message into the network after it has been automatically 
processed and handled by a server which distributes his 
origination in any and all formats necessary to be received 
by any of the receiving appliances using the compatible 

is protocol. Such a system and methodology is now possible 
with the presently described system and methodology. 

Referring to FIG. 1, there is seen a flexible, multi-user 
network system whereby a client-user is capable of author- 
ing text, graphics, or messages which can be distributed to 

20 multiple receiver terminals regardless of the format and 
protocol requirements that these receiver terminal appli- 
ances are subject to. 

As seen in FIG. 1, a client personal computer 10 which 
uses a Web Browser is connected to network 40 as is also the 

25 personal computer client 20 and the mail user client 30. This 
could also include a unit designated as a News Network User 
in the personal computer client 33. 

As seen in FIG. 1, the client Personal Computer (PC) 10 
uses the HTTP protocol (Hyper Text Transport Protocol). 

30 This is a client-server protocol used for information sharing 
on the Internet and is the basis of use for the World-Wide 
Web (WWW). The PC client 20 is seen to have a Web 
Browser using the FTP (File Transfer Protocol). FTP pro- 
vides a set of commands to log onto a network, to list 

35 directories and to copy files. 

The Mail User Client 30 is seen to use the SMTP protocol 
which denotes Simple Mail Transfer Protocol. This is a 
messaging protocol used by software applications to send 

^ e-mail to receiving terminals. 

A further client indicated in FIG. 1, is a unit designated as 
the News User used in the personal computer client 33. This 
unit uses a particular protocol designated as NNTP or News 
Network Transfer Protocol. 

45 As seen in FIG. 1, the Network 40 is connected for 
communication to the Server 50. The Server operates as a 
computer in a network shared by multiple users. It can act 
as a file server whereby it uses a high-speed computer to 
store the programs and store the data files and messages 

50 which are shared by the various users on the network. 
Sometimes this is called a "network server", since it acts like 
a remote disk drive. The Server 50 can also act as a database 
server in that it is dedicated to database storage and retrieval. 
The Server 50 is seen to provide a multiple number of 

55 server processes 52a, 52r>, . . . 52ai, which provide programs 
(in the Server Processes module 52) which implement the 
operation of the Server 50. 

Within the Server 50 is a database 58 which provides an 
electronically stored collection of data. The database 58 is 

60 managed by the database manager 54, which involves soft- 
ware that allows a user to manage multiple file and message 
"objects". In the present embodiment, the module 54 is a 
specialized database manager called OSMOS. OSMOS is a 
specialized system which is an object database management 

65 system. 

The OSMOS database manager 54 provides software that 
enables database management capability for traditional pro- 
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gramming languages, such as COBOL, BASIC, and C and SUMMARY OF THE INVENTION 

C++. It also enables the storage and retrieval of data from the _ , , , . . , 

database 58 ^ e P resent system and methodology provides for the 

The operational functioning of the OSMOS database origination and storage of a "source" document as a desig- 

manager 54 is handled by the unit designated Schema 56, 5 nated ob J ect in an ob ^ ecl database, A source document can 

which defines the entire database. The Schema 56 sets up the be submitted in the form of a "file" in which case it is stored 

organization of the database and the ways that the entire as a "Virtual File" object. A Virtual File object is analogous 

database 58 is used. to a normal system file except that, as a database object, it 

Further, as seen in FIG. 1, the Server software processes nas additional properties and behavior that a system file 

module 52 is connected to the Public Switched Telephone a0 normally does not have. Virtual File objects are organized 

Network 60 (PSTN), which provides connection lines to the into named directories, each of which are also represented in 

telephone 80 using Interactive Voice Response applications the database as an object. 

(IVR). IVR applications provide pre-recorded information Alternatively, a source document can be submitted in the 

either with or without selection by the caller. IVR applica- form of a "message" such as an e-mail message or news 

tions also allows interactive manipulation of a database. In ^ article In mis casCj it ^ stored ^ a "Virtual Message" object 

response to a voice menu, users press the keys or answer within the databaset virtual Message objects are organized 

questions to select their way down a path i of choices. IVR accordiog t0 their purpose) such ^ whether lh are 

applications could be used for obtaining the latest financial intended for e _ mail newsuserSj or other users utilizing 

quotes, as well as for ordering various products. They can . ■ , . , .... , t 

1 < i i ■ * * * ii i.i \ , some other message-oriented protocol. Virtual File objects 

also be built into interactive systems to allow databases to be „ t ,„ , & . t , r t «w 

changed 20 are P oste d DV connecting them to one or more Message 

« J AV i- -n c pjjn( - . , Board" objects. Each Message Board object is named and 

The FAX appliance 70 of FIG. 1 operates on a special . i . , r u i_ -i r u 

format designated as the Group 3 Facsimile Protocol which represents a logical folder such as a mail folder or news 

is widely used for facsimile transmission. g rou P- 

The present system provides a means for communication terms "Virtual File", "Virtual Message", and "Mes- 

between multiple users, together with a simpler and more 25 sage Board" refer to different kinds of "resources". Any 

expanded method for sending data to different types of document that can be authored and therefore have "content" 

appliances using different formats and operating under dif- is stored within the database as a resource object. Using 

ferent protocols. This is handled by the Server 50, which object technology classification techniques, each resource 

provides specialized techniques, as will be discussed object is then classified as a Virtual File or Virtual Message 

hereinafter, which permit a single originator to communicate 30 object and then further classified based on "file" content type 

to multiple different types of recipient terminal appliances. or "message" type. 

These terminal appliances include both telephone and FAX Documen ts are transmitted from a User-client to a server 

machines and e-mail, Web Browser, and News Users, all , , . _ , . . , f , orii nc o « D ™,.,~> .„ 

. ' . , t, ' ■ v 1 r * and stored in an object database as a Resource Object . 

operating via different protocols. These specialized features J J 

are provided for by the utilization of a specialized server 35 When a User connects to a server using a particular 

having the controlled database manager 54 designated protocol and seeks a document via a "get" request, the server 

OSMOS where the protocol "envelopes" for handling docu- finds the corresponding resource object and, if necessary, 

ment content are controlled by the server processes module can dynamically mo dify its characteristics to accommodate 

52 formatting requirements requested by the User and/or for- 

Tlie Server module 50 provides a mechanism that enables 40 mattin S required by the protocol being used. A 

secure communications to occur between the clients, such as document can be dynamically converted into a wide range of 

10, 20, 30, 33 etc., and the Server 50. It provides a database f ° rmats and ac v ! a a Wlde ran ? e of P™^™ 1 * 

repository for all documents, together with the ability to the document s author having to anticipate the formats and 

index and search the documents with a powerful search Protocols that users may require ahead of time, 

engine. The search engine and its supporting database 58 45 A dynamic conversion methodology is provided to use 

uses the OSMOS 54 database manager to manage the Resource objects in the database to set up a requested 

storage, verification, and access to resident documents document in the format appropriate to the User-requester, 

which include embedded graphics, sound clips, and video The dynamic conversion technique utilizes a "converter", 

clips. which is another type of "object" within the database. Each 

As will be discussed hereinafter, the Server 50 includes a 50 converter object has the ability to transform one kind of 
set of conversion filters (converters) which provide "on-the- resource object into another kind of resource object. When 
fly" conversion of documents authored in one specific a User requests a document's content in a format different 
format to be transformed into other formats for display, for than that in which it is currently encoded, and/or if the 
printing, for e-mail or voice or for FAX appliances. The document is requested using a protocol with which the 
database software "converts" an incoming document request 55 document is not immediately transferable, the server auto- 
into the appropriate format that is required by the "outgoing" matically finds and utilizes a converter object which trans- 
client display device, whether it be a FAX appliance 70, a forms the document's content to a format compatible with 
File Transfer Protocol (FTP) Browser 20, a Hyper Text the request. The selection of a converter object and the 
Transfer Protocol (HTFP) Browser 10, or voice for the dynamic conversion of the document's content take place 
telephone 80. 60 automatically, without the requesting User aware of the 

The present system enables a user to author documents operation and without the document's author having to 

once, and the system provides a dynamic conversion system specially prepare the document before hand, 

for enabling multiple types of format conversion. The dynamic conversion technique works equally well for 

Additionally, the system handles both file and message conversion from one resource type to another and/or from 

documents for delivery to a requester while supporting the 65 one content format to another. For example, one converter 

appropriate protocol to carry and deliver the content of the object could convert an e-mail message into a text file, while 

document. another converter could convert a plain text file to an HTML 
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file. Multiple converter objects can be used in a single Low-level protocols define the electrical and physical stan- 
document retrieval request so that a resource object's con- dards to be observed, such as bit-ordering and byte-ordering 
tent can be converted both to another resource type (e.g., and the transmission and error detection and correction of 
message to file) and to another content format (e.g., plain tQe bit stream. High-level protocols deal with data 
text format to HTML format). Consequently, converter 5 formatting, including the syntax of messages, the client- 
objects can be used to convert a resource to accommodate dialog, character sets, and sequencing of messages, 
different content formatting requirements (e.g., plain text, M used herein » the term "protocol" refers to the highest- 
HTML, postscript) as well as different protocol require- level P rotoco1 employed by a given client-to-server connec- 

ments (e.g., mail, news, FTP, etc.) tlon ' 

10 Referring now to FIG. 1, a specialized Server 50 is 

BRIEF DESCRIPTION OF THE DRAWINGS connected to the network 40. The network 40 has commu- 

FIG. 1 is an overall network diagram showing the inter- nication connections to the client 10, the client 20, the client 

related modules which function to utilize the methodology 30 and lhe ciient 33 > each of which involves different 

of the present system of dynamic format conversion and communication protocols. Further, the Server 50 also has 

protocol transport- 15 communication connections to the Public Switched Tele- 

FIG. 2 is a dra^ng which illustrates the "resource" object Network 60 1, which enables communications to and 

types used within the database. It shows how the Resource f ™ m ' h , e machine 70 with a facsimile protocol and wrth 

object type is subdivided into the Virtual File, Virtual the Tele P h ° ne 8 « « s "i8 an Interactive \fo.ce Response 

Message, and Message Board object types, each of which P ro oco ' 

are further subdivided into additional object types; 20 The generalized problem faced by client users in this type 

™~ ,. t ,. 1 1 ■ , . . of network is that the user will author or originate "source" 

FIG. 3 is an object hierarchy diagram showing how the . c ... . , . 

w. 1 f-i u- \ • , v , ■ , n' , j intormation in one particular format designated for various 

Virtual File obiect type is subdivided into Directory and . . t , 4 , A \, 

» m/r -pi«i , . . . wywt-> n-1 * a *u u' * j j recipients but that the recipients use different document 

MIME File obiect types. MIME File is further subdivided c r A c it . r I( . , 

u- * * a f j • # x*!*^ * a *u tormats tor their appliances and/or completely different 

into obiect types first according to MIME type, and then . ~ 1 / 

.wywp, u' . . * j* -j -1 a' \ wTwr* 2s protocols. For example, the author may create a source 

each MIME type object type is divided according to MIME i:> *, , . fc ,. * ' , r . 3 , _ 

. document in Microsoft Word format and store it at the Server 

* ,. . , , , using the FTP protocol. Another user may wish to access the 

FIG. 4 is an object hierarchy diagram showing how the document as an HTML file using the HTTP protocol. Yet 

Virtual Message and Message Board object types are another 

user may wish to access the document as an e-mail 

divided into subtypes based on the purpose of each object 3o message using a mail protocol such ^ mAp (Intemet 

type s corresponding objects; Message Access Protocol). Still another user may wish to 

FIG. 5 is an object hierarchy diagram showing how the listen to an audible rendition of the document using a 

Converter object type is divided into object types first based standard telephone. 

on "output" resource type and then on "input" resource type; With oldef systemS} the author must anticipate the needs 

FIG. 6 illustrates an example of a dynamic content 35 0 f each recipient, and he must manually convert his infor- 
conversion session, A Web Browser is shown requesting a mation into multiple formats to meet not only their format- 
file in a format different from that in which it is stored, ting requirements but also the requirements of the commu- 
requiring its content to be transformed via a file-to-file nication protocols that they wish to use. For example, if the 
converter; source document is an image file in JPEG format and at least 

FIG. 7 illustrates the same document, a file, being 40 one recipient requires the image in GIF format, the author 

dynamically converted to accommodate different format and must manually convert the JPEG file into a GIF file, 

protocol requirements; Furthermore, if at least one recipient wishes to receive the 

FIG. 8 is a flow chart illustrating the procedural steps used GIF file via e-mail, the author must also encode the GIF file 

to send documents to the server and store them as resource with a "transfer encoding" technique since GIF files contain 

objects; 45 binary codes which are not directly transferable via standard 

FIG. 9 is a flow chart showing the series of steps whereby e-mail protocols. With the system described herein, a user 

a source document is requested and dynamically converted can author information once and store it in a centralized 

into a format which matches the requirements of the server, and the system will dynamically convert the infor- 

requester. mation as needed into a format that accommodates both the 

npcruiDTinM nn tup oppppporn 50 formattin g and protocol requirements of a specific recipient 

UbbLKlrllUN UF 1HL PRbFhKRbU who ^ reqU esting the information from the server. 

In order for information to utilize the dynamic conversion 
Before describing the details of the current invention, methodology, a user must first create or obtain the source 
some terminology used herein is defined. The term "format" information in the form of a document. The source docu- 
refers to the specific arrangement of data on a disk or other 55 ment must then be stored at the Server 50. The author 
storage media in order to meet established application accomplishes this by using a Client tool and connecting to 
requirements. For example, a file can be stored in the format the Server using any of a wide range of protocols such as the 
of a certain application such as Microsoft Word; an inter- File Transfer Protocol (FTP), Hyper Text Transfer Protocol 
national standard format such as Hyper Text Markup Lan- (HTTP), Simple Mail Transfer Protocol (SMTP), or the 
guage (HTML); or a generic application "neutral" format eo Network News Transport Protocol (NNTP). Typically, a user 
such as "plain text". In addition to their use within disk files, will use a Client tool best suited for the type of document 
formats can also be used within portions of messages sent that he has authored, including its purpose and format. For 
over a network. For example, an "attachment" within an example, if the document is authored as a file, he will use a 
e-mail message can utilize a specific format such as plain Client tool that uses a file-oriented protocol such as FTP. If 
text or HTML. 65 the document is authored as a message such as an e-mail 
The term "protocol" refers to a set of formal rules message, he will use a Client tool that uses a message- 
describing how to transmit data, especially across a network. oriented protocol such as SMTP. Any protocol which can 
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connect to the Server and perform a "send" command can be 
used to deliver a document to the Server. 

The Client tool's "connect" request causes one of the 
Server Processes 52 to be started. A specific type of Server 
Process is started which can handle the protocol being used 
by the Client. The Server Process "opens" the database by 
communicating with the OSMOS Database Manager 54. 
The author must then perform a "put" or "send" command 
as provided for by the protocol that he is using. The "put" or 
"send" command causes the document to be sent to the 
Server and received by the Server Process. The Server 
Process in turn directs the OSMOS Database Manager to 
create an "object" and store it within the Database 58, The 
Server Process further directs the OSMOS Database Man- 
ager to store the document's content within the database as 
one or more properties of the object. 

The database object created on behalf of the document 
represents a "virtual" form of the document because it is 
accessible in its original form (as a file or a message), but it 
is realized as a database object. The type of objects that can 
be stored within the database and the operations which can 
be performed upon them are defined in the database schema 
56. The encoding of special functions, called "methods", 
which can be used to manipulate objects, are contained 
within the Method Library 55. When a Server Process 
directs the OSMOS Database Manager to create a database 
object or perform some other function on a database object, 
the OSMOS Database Manager performs some of these 
requests directly on the Database 58, while some requests 
are routed to the Method Library for execution. The func- 
tions within the Method Library are largely responsible for 
controlling the type and properties of the database object 
created on behalf of a document. 

Referring to FIG. 2, the database object created to hold the 
document's content is a "resource" object. This means that 
the object belongs to the "Resource" type 10R, which is the 
root type of an object hierarchy. A resource object is created 
for each document which possesses content. If the document 
is delivered as a file, the resource object is also inserted into 
the Virtual File type 20V, which is a "subtype" of the 
Resource type. Alternatively, if the document is sent as a 
message, the resource object is inserted into the Virtual 
Message type 30VM, which is also a subtype of Resource. 
(Objects of type Message Board 40MB are not created as a 
result of a document "put" request but rather by other 
commands used by various protocols.) In addition to the 
Virtual File or Virtual 

Message subtype, the resource object is inserted into 
additional subtypes depending upon other characteristics of 
the document. Referring to FIG. 3, if the Resource object is 
a Virtual File object, it is inserted into one or more lower- 
level subtypes of the Virtual File type. This is done by 
determining the file's "MIME type" and using this informa- 
tion to include the object in a matching subtype. For 
example, if the file is a "plain text" file, the object is included 
in the Plain Text File subtype. If the file is a GIF image file, 
the object is included in the GIF File subtype. MIME refers 
to the "Multi-purpose Internet Mail Extensions" standard, 
which extends the SMTP standard with a means for classi- 
fying the content of e-mail messages. The use of the MIME 
standard within an object database in order to effectuate a 
"Virtual Multimedia File System" is the subject of the 
co-pending patent application U.S. Ser. No. 08/769,199 
entitled "A Method for Storing/Retrieving Files of Various 
Formats in a Object Database Using a Virtual Multimedia 
File System". 

When a document is submitted as a file, the author gives 
it a file name, which is stored as a property of the Virtual File 
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object. This allows the Virtual Object to be later retrieved by 
the same file name. 

Referring to FIG. 4, if the Resource object is a Virtual 
Message object, it is also inserted into a subtype of the 
Virtual Message type. The subtype employed will match that 
of the protocol being used to send the document. For 
example, if an e-mail protocol is being used (e.g., SMTP), 
the object is included in the Mail Message type. If the 
protocol is a news protocol (e.g., NNTP), the object is 
included in the News Message type. The storage and 
manipulation of messages as objects within a "Virtual Mes- 
sage System" is the subject of the co-pending patent appli- 
cation U.S. Ser. No. 769,200 entitled "A Method for 
Abstracting Messages of Various Protocols Into Objects for 
Storage in a Database". 

A message document is always "posted" to one or more 
"Message Boards" as identified in the "send" command. 
This means that the Virtual Message object is connected to 
appropriate Message Board objects using object connecting 
techniques. The message document can be subsequently 
retrieved by submitting the name of a message board to 
which it is posted and a "message number" which identifies 
the posting position within the message board. Often, a 
message document will be assigned a unique "message id" 
which also can be used as an alternative method for locating 
the message. 

The Resource object created on behalf of the document is 
assigned "properties" that represent the document's content 
and identity. After successful creation of the database object, 
the Server Process returns a successful result code back to 
the Client. The source document is subsequently available 
for access by any Client connected to the network. 

The steps for sending a document from a client to the 
Server and storing it in the database as a resource object is 
depicted in FIG. 8 and summarized below: 

(i) A User utilizes a client tool (10, 20, 30, or 33) to 
connect to server 50 via network 40. 

(ii) The client tool's "connect" request causes a Server 
Process 52 to start activity particular to the type of 
protocol used. 

(iii) The User performs a "send" request to transmit a 
document to the Server 50. The "send" request is 
accompanied with document identification such as a 
file name or a message id. If the document is a message, 
it is accompanied with a list of message boards to 
which the message is be posted. 

(iv) The Server Process 52 uses the identification infor- 
mation to create an appropriate resource object. If the 
document is a file, a Virtual File object is created whose 
subtype corresponds to the file's MIME type and 
subtype. If the document is a message, a Virtual Mes- 
sage object is created whose subtype corresponds to the 
message's purpose. The document's content is stored 
as one or more properties of the object. 

(v) If the object is a message, it is posted to each requested 
message board. 

(vi) A result code is returned to the client. 

Referring back to FIG. 1, the process for retrieving 
documents and the dynamic conversion methodology is now 
described. In order to retrieve a document, a user utilizes a 
Client tool such as 10, 20, 30, or 33 to connect to the Server 
50 via the Network 40. Or, the user can use a telephone 
appliance such as a FAX machine 70 or a Telephone 80 to 
connect to the Server via the public telephone network 60. 
The user utilizes a Client tool and protocol that best suits the 
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way in which he wishes to use the document. The user can the user's "get" request. For example, some protocols, such 

utilize a tool that uses a file -oriented protocol such as FTP as HTTP, can specify a list of one or more MIME types that 

or HTTP, or a message-oriented protocol such as NTTP or- the Client tool can handle. FAX machines must be sent 

POP3. In general, any tool that uses a protocol that is information in a Group 3 Protocol image format. It is 

capable of performing a "get" request can be used to retrieve 5 possible, therefore, to recognize that the Client can not 

documents from the Server. (In the case of FAX machine handle the format with which the document is currently 

access, the Server must initiate a FAX "send" request, but stored. For example, a Client can retrieve an image docu- 

this could be prompted by a "FAX back" request given from ment stored as a JPEG File but specify in the "get" request 

some other client tool such as a telephone or Web Browser). that only GIF format image files can be handled. In this case, 

The Client tool's connect request causes a Server Process 10 the most desirable effect would be to translate the JPEG 

52 to be started specific to the type of protocol being used. document into an equivalent GIF document. 

The user then performs a "get" request for the document he Another situation that can occur is that the document 

seeks in accordance with the protocol that he is using. The selected by the "get" request is not stored in a format that can 

"get" request must be accompanied with some kind of be handled by the protocol being used. This always happens, 

identification of the document such as a file name or is for example, when a file is retrieved via a message-oriented 

message id. Typically, file-oriented protocols such as FTP protocol because message protocols require separate "enve- 

will use a file name to identify the target document. lope" and "body" components whereas files only possess a 

Message-oriented protocols will use either a message id "body". This situation requires that a suitable envelope be 

(identification) or a combination of a message board name generated to match the requirements of the protocol, 

and a message number to uniquely identify the message.) 20 Furthermore, some message -oriented protocols can not 

The Server Process uses this identification information to directly transfer binary data whereas some document for- 

call the Database Manager 54 and attempt to locate a mats allow binary data. In these cases, the binary data must 

resource object in the Database 58 that corresponds to the be encoded with a "transfer encoding" scheme which the 

document. protocol will allow and that the Client can decode to 

The retrieval algorithm allows any resource to be found 25 reproduce the original content, 

using any protocol. In the simplest cases, the document is If the Server Process 52 detects that the Resource object 

sought with the same protocol or a similar protocol with selected is already stored in a format which is compatible 

which it was originally stored. For example, if the document with the "get" request, then the object's content is simply 

was stored as a file, it can be sought via any file-oriented extracted and returned to the client following the rules 

protocol by supplying the same file name that was originally 30 stipulated by the protocol. 

assigned to the file. If the document was stored as a message, However, if the resource object's current content format 

it can be sought by supplying the same message id with is not compatible with the "get" request for some reason, 

which the message was stored, or it can be sought by then the Server Process 52 attempts to locate a "converter" 

supplying the name of one of the message boards to which object which will convert the content into a compatible 

it is posted along with a message number that uniquely 35 form. Referring now to FIG. 5, the database 58 possesses an 

identifies the posting within that message board. object hierarchy known as the "converter object hierarchy". 

If the document is sought with a substantially different The Converter type 10C is the root of the hierarchy. The 
protocol than that used to store it, a "pseudo name" can be Converter type is divided into subtypes that represent "out- 
used to find the document. For example, if the document was put resource" types: File Converter 20FC, which will pro- 
stored as a file but is being sought via a message-oriented 40 duce output in a file format; Message Converter 30MC, 
protocol, it can be retrieved by submitting a message board which will produce output in a message format; and Mes- 
name equal to the file's file name and by submitting a sage Board Converter 40MBC, which will create or main- 
message number equal to 1. If the document was stored as tain a message board as its output. Each "output" converter 
a message and is being sought via a file-oriented protocol, it type is further divided into subtypes that represent an "input 
can be retrieved by submitting a file name that identifies the 45 resource**. For example, the File Converter type has the 
type of message board desired, the name of the message subtypes: File-to-File Converter, which accepts file content 
board, and the message number. For example, the file name: as input; Message-to-File Converter, which accepts message 

content as input; and Board-to-File Converter, which accepts 
an entire message board as input. 

"#ncw 5 ycom P .anix.m l sc/3" $q ^ bottom . most (FIG 5) or « leaf > Converter types (e.g., 

could denote that the user is seeking the third message File-to-File Converter, Message-to-File Converter, etc.) 

(denoted by the "3") posted to a message board (denoted by have additional "properties" which further define the kind of 

the "#" symbol) that is a news group (denoted by the term conversion that objects of that type will perform. Many leaf 

"news") whose name is "comp.unix.misc". Because docu- Converter types are assigned an "input MIME type" and an 

ments are stored as logical objects within the database, a 55 "output MIME type" which define the format of data that 

variety of methods can be implemented to allow them to be they can receive and the format of data that they will 

searched and retrieved. Consequently, a variety of pseudo generate. So, for example, the File-to-File Converter type 

name schemes can be used to allow documents to be has both input and output MIME type properties, hence a 

retrieved by a wide range of protocols. specific File-to-File Converter object can indicate that it can 

If, after taking into account the protocol being used and 60 accept "image/JPEG" input and produce "image/GIF" out- 

available pseudo name schemes, the Server Process 52 put. This means that the object can accept a JPEG File object 

cannot find a resource object that matches the "get" request, as input and produce an equivalent file (that represents the 

an error is returned to the user. same picture) in GIF output. 

If the "get" request successfully identifies a resource The Converter type hierarchy is populated with numerous 

object, the Server Process 52, with assistance from the 65 converter objects, each of which can perform a specific 

Method Library 55, determines if the object's content is in conversion. All Converter objects possess a "transform" 

a format that is compatible with other parameters given in function which can be called to perform its corresponding 
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conversion process. The actual algorithm used by each locates a "converter" object which will convert the 
Converter object's "transform" function depends on the document's content into a format which is compatible 
particular type of transformation that it performs. Some with the client's protocol and all other parameters 
conversions are simple and some are very complicated. The specified in the "get" request. If no suitable converter 
present system is provided with several hundred converters, 5 object is found, an error is returned to the client, 
which handle the conversion of numerous text, image, (vii) If a suitable converter object is found, its "transform" 
video, audio, and other formats. Furthermore, the Converter function is called with the resource object's content 
type provides "search" functions that a Server Process can passed as a parameter. The resulting transformed con- 
use to locate an object that fulfills a specific conversion tent is returned to the client. 

requirement. 1Q An example dynamic conversion session is depicted in 
Consequently, when a Server Process 52 discovers that its piG. 6. As shown, a Client represented as a Web Browser 10 
"get" request is requesting a document which can not be is using the FTP protocol. The client has sent a "get" request, 
delivered to the Client in its current form, it searches the shoWQ on line ( a)> for the file 20VF whose name fe « in f o rtf • 
Converter hierarchy for an object which can convert the Furthermore, the "get" request includes a parameter that 
document to a form which the Client can handle. The search requests the file in image/tiff formaU (TIFF represents 
includes "keys" which specify both input and output Tagged Image File Format } Ho wever, the content of the 
resource requirements, input and output MIME type corresponding Virtual File object is stored in text/rtf format, 
requirements, if any, and other parameters such as an output (RTF represents Rich Text Format.) Consequently, a File- 
transfer encoding scheme. Thus, the Server Process can t0 . File Converter object 30F F has been located which con- 
locate a Converter object that satisfies not only a resource verts text/rtf files to image/tiff files. As shown on line (b), the 
conversion due to protocol requirements (e.g., accessing a Virtual File object > s text/rtf contem is extracted and passed 
file via a message protocol or vice versa), but a format t0 the Converter object's "transform" function. The output 
conversion as well (e.g., accessing a JPEG image when a of the transform f unc tion is the equivalent content in image/ 
GIF image is required). tiff f ormat) and this con tent is returned to the Virtual File 
If no Converter object exists that will satisfy the required o5ject ^ snown on , ine (c) image/liff content ^ then 
conversion, either an error is returned to the Client or the appropriately packaged as an FTP response and returned to 
document is returned "as is" to the Client anyway, depend- the clieptj as shown on line ( d ) 

ing upon Server configuration options. If a suitable Con- Another dynamic aversion example is depicted in FIG. 
verier object is found, its transform function is called, 7< In this example> three separate Clients are requesting the 
passing the found document's content as the input param- document 10 named "info.rtf ', which is a Virtual File whose 
eter. The transform function's output, which is now in the contem ^ stored in text/rtf format Howeverj each client has 
desired format, is returned to the Client to satisfy the "get" different requirements- 
request. 1) The Web Browser 50 is using the HTTP protocol and 

In summary, the Converter object type hierarchy has ^ requesti the doc ument in text/html format, 

numerous converter objects, each of which can perform a — . ., , /k . . T ,, Ar , , . . 

-pT t , . t 35 2) The Mail User 60 is using the I MAP protocol and is 

specific conversion. Each converter object processes a ' At _ , & , , r 

„f c »» . • », i_ * i_ i_ 11 1 . c requestmg the document as a standard mail message, 

transform function which can be called to perform a u* u j . .l »mir r . ! 

t . , r which corresponds to the MIME format message/ 

particular conversion process. rfc822 

The dynamic conversion methodology is depicted in FIG. , tI „_ . . „,„ 

9 and summarized below: 3 ) . rhe Tele P hone User 70 > s using an I VR application and 

A TT .... 1- . . 1 /in -ia in . 40 is requesting an audio rendition of the document, which 

(1) A User utilizes a client tool (10, 20, 30, or 33) to 7 . % , . , ' 

w 4 t en • * 1 An \ i u can be satisfied by sending the document s content in 

connect to server 50 via network 40 or a telephone ,. r t J . & « . 

, c * • ts\ 1 i_ on . an audio format such as audio/basic, 

appliance such as fax machine 70 or telephone 80 to ™ 4 . c , ™. , , ^ \ 

rr , . _ n . . , . . r , , To satisfy each Client s requirements, three separate Con- 1 

connect to server 50 via public telephone network 60. t .... . , \ , ^ ^-i t-m ^ 

^ „ « „ ^ verter objects have been located. The File-to- File Converter 

(u) Hie client tool s connect request causes a Server 45 20FF reads the file's content and performs only a MIME 

Process 52 to start activity particular to the type of lype (text/rlf t0 text/html) , File-to-Message 

protocol used. Converter 30FMC is converting the file format into a > 

(iii) The User performs a "get" request to retrieve a message format> and it ^ also ^y^g thc RTF format/ 
document from the Server 50 (for fax machme access, int0 a proper e . mail message (RFC822) format. The File-/ 
the Server initiates a fax "send" request). The "get" 50 to -File Converter 40FF is converting the text/rtf content into \ 
request is accompanied with identification of a docu- . an audio/bas i c format) which ^ sent via the IVR application \ 
ment such as a file name or a message id. If the as an audio p i ayback t0 the requester's telephone. ITie / 
document is sought with a substantially different pro- output of each Converter object's transform function is / 
tocol than that which was used to store it, a "pseudo rouled back t0 the appr opriate user. 

name" can be used to find the document. 55 By p re .po P ulating the Converter hierarchy with various 

(iv) The Server Process 52 uses the identification infor- objects that satisfy a wide range of conversion needs, a 
mation to call the data base manager 54 to locate a Server can automatically and dynamically convert a docu- 
resource object in the database 58. If no matching mcrit mt0 a i arge number of possible formats to satisfy a 
resource object is found, an error is returned to the user. broad set of clients. Furthermore, since the Server Process 

(v) When the "get" request successfully identifies a 6 0 searches for an appropriate Converter object each time a . 
resource object, the Server Process 52 (assisted by document conversion is required, a new Converter object 
Method Library 55) determines if the object's content can be added to the database and will be immediately 
is in a format compatible with the client's protocol and available for both new and existing documents. 

other parameters in thc "get" request. If the document Note that if a Server Process 52 cannot find a Converter 

is compatible, it is returned to the client. <js object which will directly handle a desired conversion, it can 

(vi) If the client cannot handle the format in which the use a feature known as "converter chaining". For example, 
document is currently stored, the Server Process 52 if the Server Process 52 wishes to convert a JPEG file into 
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a TIFF file (e.g., for faxing purposes), it may not be able to 
find an appropriate JPEG -to -TIFF converter. However, it 
may be able to find a Converter object which will convert the 
JPEG image into a temporary intermediate file such as a GIF 
file such that a second converter object can convert the GIF 5 
file into the desired TIFF file format. This technique of 
"converter chaining" can be extended to an arbitrary degree 
so that a much larger number of conversions can be per- 
formed than the number of conversions possible without 
chaining. 10 

Described herein has been a multi-user network where 
multiple client modules operating with different protocols 
may receive an original source document in the properly 
compatible format for that receiving client module. Further, 
a User has the capability of authoring a single Source J5 
document and publishing it to multiple receiver appliances, 
each of which will receive it with the appropriate format and 
carried with the appropriate protocol. 

While other embodiments of the described concept may 
be implemented for similar purposes, the present network 2Q 
and methodology is encompassed by the following claims. 

What is claimed is: 

1. In a computer network having multiple sending- 
receiving appliances and supporting multiple User-clients 
who can function as a User-author or User-requester, where 25 
each User-client utilizes a computer terminal serviced by a 
server module with an object database, a method for 
enabling a client User of any one of said appliances to 
communicate with any other client User of said appliances, 
comprising the steps of: . 30 

(a) creating a source document in a first format as an 
object in said database, said document constituting a 
file or a message as an object in said database; 

(b) establishing a plurality of database objects, said 
objects including a hierarchy of resource objects which 35 
include (i) a virtual file object utilizing a MIME format 
which provides multiple sub-objects for text file, image 
file, audio file, video file, application file, message file, 
multi-part file and experimental file, (ii) a virtual mes- 
sage object providing virtual message sub-objects des- 40 
ignated mail message, news message, chat message, 
miscellaneous message, and, (iii) a message board 
object providing sub-objects designated mail folder, 
news group, chat channel, message reflector, file 
reflector, and miscellaneous message board, and 45 
additionally, a class of converter objects which (iv) 
provide a file converter object, a message converter 
object, and a message board converter object, each of 
which provides sub -objects which provide transforma- 
tion between the file converters, message converters 50 
and board converters; 

(c) enabling any User-client to install a source document 
in said object database and to transmit the content of 
said source document to each one of the client Users 
and appliances connected to the network, in a format 55 
and transport protocol compatible with each of the 
receiving clients, or appliances, capabilities. 

(d) utilizing a dynamic format conversion search and 
transformation means for locating the appropriate con- 
verter objects in said database and to utilize their 60 
format transformation functions to provide compatible 
formats for transmission to each one of said receiving 
appliances and client-Users, together with a protocol 
compatible to the said appliances and users. 

2. In a computer network having multiple sending- 65 
receiving appliances and client- Users, each having different 
format requirements and operating protocols, wherein said 
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network is supported by a server using an object database, 
a method for enabling any one of said appliances or client- 
Users to communicate with any other of said appliances or 
client-Users comprising the steps of: 

(a) establishing, by a client-User, a source document in a 
first format as an object in said database; 

(b) establishing an organized hierarchy of database 
objects which define the document content via a virtual 
file object, a virtual message object, or a message board 
object, each said virtual file object, virtual message 
object, and virtual message board object, including 
multiple sub-objects, said virtual file objects utilizing 
the MIME format to communicate with multiple sub- 
sets of file objects, said virtual message object com- 
municating with multiple subsets of objects for mail 
message, news message, chat message, and said mes- 
sage board object, including a subset of message board 
objects for mail folder, newsgroup, chat channel, mes- 
sage reflector, file reflector and miscellaneous message 
boards; 

(c) establishing an organized hierarchy of database 
objects organized in a class of converter objects which 
provide a file converter, a message converter, and 
message board converter, where each said file converter 
object, message converter object, and message board 
converter objects provide multiple subset objects which 
transform documents between files, messages, and 
message boards; 

(d) receiving call requests and "get content" requests from 
said client users; 

(e) identifying the protocol and format utilizable by each 
of said client Users or receiving appliances; 

(f) searching said database and identifying the appropriate 
converter for transforming the format of said source 
document, said search involving the utilization of a 
converter object hierarchy which involves a file con- 
verter object, a message converter object, and a mes- 
sage board converter object, each of which has subset 
objects which relate files to message boards; 

(g) transmitting said source document in a format and 
protocol compatible to a client user connected to the 
network. 

3. In a network having digital appliances and User clients 
with computer terminals connected via a switching network 
to a content server, a method for enabling a source document 
created in said content server to be transmitted to any of said 
digital appliances or said client-Users: 

(a) creating a source document as a resource object in an 
object database which has a plurality of resource 
objects working through a MIME file object including 
file -oriented objects and message -oriented objects, and 
including a plurality of specialized converter objects; 

(b) enabling a client User-requester to request said source 
document; 

(c) searching said object database to select a converter 
object which can dynamically convert said source 
document from a first format into a second format 
compatible to said client User- requester's requirement 
or said digital appliance's requirement; 

(d) utilizing a selected converter object in said object 
database to convert the content of a requested docu- 
ment to a format compatible with a user-reauester's 
format and protocol, said converter object utilizing a 
hierarchical converter object and subset objects which 
include a file converter object, a message converter 
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object and a message board converter object, where- 
upon each of said file converter object, message con- 
verter object and message board object have subset 
objects which can inter- relate and transform files to 
messages to message boards or vice-versa; 
(e) enveloping said second document content format with 
a protocol transmittable to said client User- requester or 
digital appliance. 

4. The method of claim 3 wherein utilizing said selected 
converter object of step (d) includes the steps of; 

(i) converting a resource object having a message orien- 
tation to a resource object having a file-orientation; 

(ii) converting a resource object having a file -orientation 
to a resource object having a message orientation. 

5. The method of claim 3 wherein step (e) includes the 
step of: 

(el) utilizing a resource object having a specialized 
converter object to initiate a protocol envelope to 
deliver document content from a file protocol orienta- 
tion to a message protocol orientation. 

6. The method of claim 3 wherein step (e) includes the 
step of: 

(e2) utilizing a resource object having a specialized 
converter object to initiate a protocol envelope to 
deliver document content from a message protocol 
orientation to a file protocol orientation. 

7. In a network wherein digital appliances and multiple 
User clients each having a computer terminal are connected 
via a switching network to a content server, a system for 
enabling the creation of a source document in an object 
database and for enabling transmission of said source docu- 
ment to a client-User requester or a digital appliance com- 
prising: 

(a) means to originate and store a source document as an 
object in an object database, said object being desig- 
nated as a resource object; 

(b) said object database for holding objects designated as 
resource objects which include Virtual File objects 
based on a MIME file object, Virtual Message objects 
and Message Board objects, including a class of objects 
designated as Converter objects; 

(c) means for requesting said source document by a 
User-requester from said object database; 

(d) means to search and find the required source document 
as an object in said object database; 

(e) means for selecting a converter object to modify the 
characteristics of said source document to render said 
source document in a format compatible to said user- 
requester, said converter object organized on a hierar- 
chical basis wherein said converter object is selected to 
operate through a file converter object based on a 
MIME file object, a message converter object, or a 
message board converter object, whereupon each of 55 
said file converter, message converter and message 
board converter objects are connected to subset objects 
which correlate transformation of files to messages, 
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messages to files, files to message boards and vice- 
versa, messages to message boards and vice-versa; 
(f) means to package said reformatted source document 
into the appropriate protocol envelope for delivery to 
said User- requester. 
8. In a data processing network including at least one 
content server, a plurality of digital appliances and client- 
Users, which may include a User- author and User-requester, 
for generating an operation call, each operation call speci- 
fying an operation to be performed between each User-client 
and said server, a system for dynamically reformatting the 
content of a source document and utilizing the appropriate 
protocol for delivery of said content to a client User- 
requester or a digital appliance, comprising: 
(a) a content server connected to said digital appliances 
and said client -Users via a switching network, includ- 
ing: 

(al) an object database for holding Resource objects, 
said Resource objects including Virtual File objects 
based on a MIME file object, Virtual Message 
objects, and Message Board objects and including a 
class of objects designated as Converter objects, 
each of said Converter objects including: 
(ala) means to transform the source document's 
format into a resultant format usable by said client 
User-requester; 

(a2) a database manager means for connecting a server 
processes module means to said object database and 
including: 

(a2a) means for passing said operating call request 
and a "get content" request from said client User- 
requester to said object database; 
(a3) said service processes module means having a 

specific port connecting each of said client Users, 

said port operating on a protocol utilizable by said 

client-User and including: 

(a3a) dynamic search means to select a Converter 
object in said database necessary to transform the 
format content of said source document into the 
format required by said client-User-requester, said 
converter object providing a hierarchical organi- 
zation of objects where a file converter object uses 
the MIME format, and said hierarchy further 
includes a message converter object and a mes- 
sage board converter object, wherein each said file 
converter, message converter and message board 
converter objects are connected to subsets of 
objects which inter-relate transformation between 
files, messages and message boards: 

(a3b) means to envelop the content of said reformat- 
ted source document in the protocol utilizable by 
said client User-requester; 

(a3c) means to transmit said reformatted document 
content via the protocol appropriate for transmis- 
sion to said client User-Requester. 
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